Software copy protection is always a race between software protection vendors, their customers (i.e., Independent Software Vendors (ISVs) that utilize the software copy protection to protect their software from unauthorized copying), and software crackers who circumvent the copy protection in the computer software. Typically, when a new copy protection method comes to market (whether a radical new method or an improvement of an existing protection method), software crackers try to break it so they can sell the cracked software at a price less than the price the ISV is charging for it.
Developers of software copy protection want to make cracking as difficult and frustrating for crackers as possible. One important goal is to avoid the possibility of a cracker finding a “generic crack” whereby, once a protection is analyzed and cracked, any software using that protection can easily be cracked. This is especially important for software security vendors, whose products are used by many ISVs. The existence of a generic crack would adversely affect all of their customers (the ISVs). In contrast, if each protected application has to be cracked individually, crackers need to spend much more time and energy on each effort to crack each application, resulting in only a few protected applications being cracked during a given time period.
A software security solution can use a database, such as a structured query language (SQL) database, to store and manage license information for copy protected application software. The license information may itself be protected, such as by encrypting, when it is stored in the database. However, to make it more difficult to analyze and crack the security solution, it is desirable to make the database more difficult for would-be crackers to understand what data is stored in the database, how it is stored, and how to manipulate the records of the database. Furthermore, it is desirable to make each license database instance unique, different from all of the others. Then, if a cracker analyses one license database, that knowledge cannot be directly applied to another database instance. For example, if a database schema included labels for tables such as “License,” “License Attribute,” etc., and the license, records contained fields (i.e., table column names) like “vendor,” “serial number,” “license feature,” and the like, then a cracker could simply read the database with database browser programs and immediately see what's in it. That information could then be used in an attempt to crack the security solution. Thus, it is desirable to secure not only the data stored in a database, but to secure the database schema as well.
One solution to provide database security is to use encryption to encrypt data stored in the database. Such encryption is applied widely, and in many places it is actually mandated by law, such as the Health Insurance Portability and Accountability Act (HIPAA), or by a standard, such as the Payment Card Industry Data Security Standard (PCI DSS). In those cases, the encryption protects the data (e.g., patient name, credit card number, and the like) but does not protect the database schema (table and column names). The security threat that is protected by such a security solution is an unauthorized user stealing data from the database.
In contrast, the threat model in the case of software licensing is different. In this case, the adversary of the ISV who owns the software is the end user who would like to make and sell unauthorized copies of the software. In this case, the user has control over the database because it is used on the user's computer, such as a server. Because of this, simple data encryption won't help prevent unauthorized copying of the software, because the encryption key is embedded in the software and is accessible to the user because the software is under the control of the user. Adding an expensive hardware crypto module is not helpful for the same reason, i.e., because the end user controls that hardware as well, and would still be able to access the whole database for decoding simply by using the module.
In addition to using encryption, various methods of obscuring, or obfuscating, software operation or content are used by software vendors to protect their software. To make it more difficult for such crackers to analyze software, some software protection products employ various obfuscation methods (to hide what they are doing), and may also employ anti-debugging methods as well. For a software application that includes database functionality, it is desirable to obfuscate the database.